System and Method of Multiple Smart Card Driver Support

ABSTRACT

By thoroughly investigating compatibility of a plurality of smart card drivers to applications available on a given smart card, a smart card framework module may be afforded additional flexibility in communications with the smart card. The additional flexibility is allowed by additional checking with a plurality of smart card drivers before communicating with the smart card, rather than simply using the first compatible smart card driver found. Furthermore, when employing an application available on the given smart card, a correct smart card driver is to be selected from among the plurality of smart card drivers.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.12/628,293, filed Dec. 1, 2009, which is expected to issue on ______ asU.S. Pat. No. ______, which in turn claims priority from U.S.provisional patent application No. 61/118,861, filed Dec. 1, 2008, bothof which are herein incorporated by reference in their entirety.

FIELD OF THE DISCLOSURE

The present application relates generally to communication with smartcards and, more specifically, to a system and method for supportingmultiple smart card drivers.

BACKGROUND OF THE DISCLOSURE

A device that reads information from, or writes information to, a smartcard typically does so using a smart card reader. The smart card readermay be connected, e.g., through a directly wired connection or awireless connection, to the device, Specific software, called a“driver”, is generally executed by the device to facilitate readingfrom, and writing to, the memory component of the smart card using thesmart card reader. The driver includes an application programminginterface (API) that allows other programs to issue requests andcommands that will be understood by the driver.

Historically, for a device to use a smart card provided by a particularvendor, the device has been required to execute a driver supplied by theparticular vendor, However, as the applications available for executionon smart cards become more standardized, device manufacturers aredeveloping generic smart card drivers that work with a variety of smartcards, Unfortunately, the co-existence, on a given device, of multiplesmart card drivers can lead to situations wherein one smart card driveris selected for use in communicating with the smart card, but functionsavailable through the use of another smart card driver are desired,

BRIEF DESCRIPTION OF THE DRAWINGS

Reference will now be made to the drawings, which show, by way ofexample, embodiments of the disclosure, and in which:

FIG. 1 illustrates an environment in which a smart card is illustratedalong with a mobile communication device that communicates wirelesslywith a smart card reader;

FIG. 2 schematically illustrates the mobile communication device of FIG.1 including a smart card framework module;

FIG. 3 illustrates steps in an example method of selecting a smart carddryer to associate with the smart card of FIG. 1, as may be carried outby the smart card framework module of FIG. 2, in accordance with anembodiment;

FIG. 4 illustrates steps in an example method of importing certificatesfrom the smart card of FIG. 1, as may be carried out by the smart cardframework module of FIG. 2, in accordance with an embodiment;

FIG. 5 illustrates steps in an example method of signing a data objectwith a private key stored on the smart card of FIG. 1, as may be carriedout by the smart card framework module of FIG. 2, in accordance with anembodiment; and

FIG. 6 illustrates steps in a method, carried out by a smart carddriver, of providing a signature, generated at the smart card of FIG. 1,to the smart card framework module of FIG. 2,

DETAILED DESCRIPTION OF THE EMBODIMENTS

A smart card framework manages a plurality of smart card drivers andtheir compatibility with applications available on smart cards as thesmart cards are introduced. Through recording an association of morethan one smart card driver with a given smart card, much more of thepotential of the applications available on the smart card may berealized.

In accordance with an aspect of the present application, there isprovided a method of initializing communication with a smart card. Themethod may comprise transmitting a reset command to the smart card,receiving a response to the reset command, selecting a first storedresponse among a plurality of stored responses, determining that thereceived response is a match for the first stored response and that thefirst stored response is associated with a first smart card driver andrecording an indication of the first smart card driver in associationwith an identity of the smart card. The method may further compriseselecting a second stored response among the plurality of storedresponses, determining that the received response is a match for thesecond stored response and that the second stored response is associatedwith a second smart card driver and recording an indication of thesecond smart card driver in association with the identity of the smartcard. In other aspects of the present application, a communicationdevice is provided for carrying out this method and a computer readablemedium is provided for adapting a processor to carry out this method.

In accordance with another aspect of the present application, there isprovided, at a communication apparatus, a method of extracting a dataobject from a smart card. The method may comprise transmitting a queryto each smart card driver of a plurality of smart card drivers,receiving, from a first smart card driver of the plurality of smart carddrivers, a first response to the query, the first response including anindication that the first smart card driver supports communication withan application on the smart card, receiving, from a second smart carddriver of the plurality of smart card drivers, a second response to thequery, the second response including an indication that the second smartcard driver supports communication with the application on the smartcard and selecting a candidate smart card driver from among the firstsmart card driver and the second smart card driver. The method mayfurther comprise transmitting a data object extraction command to thecandidate smart card driver and receiving, from the candidate smart carddriver, a first data object extracted from the smart card by thecandidate smart card driver. In other aspects of the presentapplication, a communication device is provided for carrying out thismethod and a computer readable medium is provided for adapting aprocessor to carry out this method.

In accordance with a further aspect of the present application, there isprovided a method of obtaining a signature for a data object. The methodmay comprise receiving a request to sign a data object with a privatecryptographic key, selecting a candidate smart card driver from among aplurality of smart card drivers, the selecting based on the candidatesmart card driver being responsible for having imported, from a smartcard, a reference to the private cryptographic key, calling thecandidate smart card driver with the data object and the reference tothe private cryptographic key and receiving a signature from thecandidate smart card driver, the signature having been generated at thesmart card using the private cryptographic key. In other aspects of thepresent application, a communication device is provided for carrying outthis method and a computer readable medium is provided for adapting aprocessor to carry out this method.

Other aspects and features of the present disclosure will becomeapparent to those of ordinary skill in the art upon review of thefollowing description of specific embodiments of the disclosure inconjunction with the accompanying figures.

FIG. 1 illustrates an exemplary communication system 100 that includes amobile communication device 106 that is enabled to communicatewirelessly with a peripheral device in the form of a smart card reader104. A smart card 102 is illustrated as available for being received bythe smart card reader 104. The smart card 102 may be considered to be anembodiment of an element that may, more generically, be referred to asan identity verification element,

FIG. 2 illustrates the mobile communication device 106 including ahousing, an input device (e.g., a keyboard 224 having a plurality ofkeys) and an output device (e.g., a display 226), which may comprise,for example, a full graphic, or full color, Liquid Crystal Display(LCD). In some embodiments, the display 226 may comprise a touchscreendisplay. In such embodiments, the keyboard 224 may comprise a virtualkeyboard. Other types of output devices may alternatively be utilized. Aprocessing device (a microprocessor 228) is shown schematically in FIG.2 as coupled between the keyboard 224 and the display 226. Themicroprocessor 228 controls the operation of the display 226, as well asthe overall operation of the mobile communication device 106, in part,responsive to actuation of the keys on the keyboard 224 by a user.Notably, the keyboard 224 may comprise physical buttons (keys) or, inthe case in which the display 226 is a touchscreen device, the keyboard224 may be implemented, at least in part, as “soft keys”. Actuation of aso-called soft key involves either touching the display 226 where thesoft key is displayed or actuating a physical button in proximity to anindication, on the display 226, of a temporary action associated withthe physical button.

The housing may be elongated vertically, or may take on other sizes andshapes (including clamshell housing structures). In the case in whichthe keyboard 224 includes keys that are associated with at least onealphabetic character and at least one numeric character, the keyboard224 may include a mode selection key, or other hardware or software, forswitching between alphabetic entry and numeric entry.

In addition to the microprocessor 228, other parts of the mobilecommunication device 106 are shown schematically in FIG. 2. These mayinclude a communications subsystem 202, a short-range communicationssubsystem 204, the keyboard 224 and the display 226. The mobilecommunication device 106 may further include other input/output devicessuch as a set of auxiliary I/O devices 206, a serial port 208, a speaker210 and a microphone 212. The mobile communication device 106 mayfurther include memory devices including a flash memory 216 and a RandomAccess Memory (RAM) 216, Furthermore, the mobile communication device106 may include various other device subsystems 220. The mobilecommunication device 106 may have a battery 222 to power the activeelements of the mobile communication device 106. The mobilecommunication device 106 may, for instance, comprise a two-way radiofrequency (RF) communication device having voice and data communicationcapabilities. In addition, the mobile communication device 106 may havethe capability to communicate with other computer systems via theInternet.

Operating system software executed by the microprocessor 228 may bestored in a computer readable medium, such as the flash memory 216, butmay be stored in other types of memory devices, such as a read onlymemory (ROM) or similar storage element. In addition, system software,specific device applications, or parts thereof, may be temporarilyloaded into a volatile store, such as the RAM 218. Communication signalsreceived by the mobile device may also be stored to the RAM 218.

The microprocessor 228, in addition to its operating system functions,enables execution of software applications on the mobile communicationdevice 106. A predetermined set of software applications that controlbasic device operations, such as a voice communications module 230A anda data communications module 230B, may be installed on the mobilecommunication device 106 during manufacture. A smart card framework(SCF) module 230C may also be installed on the mobile communicationdevice 106 during manufacture, to implement aspects of the presentdisclosure. As well, additional software modules, illustrated as anothersoftware module 230N, which may be, for instance, a personal informationmanager (PIM) application, may be installed during manufacture. The PIMapplication may be capable of organizing and managing data items, suchas e-mail messages, calendar events, voice mail messages, appointments,and task items. The PIM application may also be capable of sending andreceiving data items via a wireless carrier network. The data itemsmanaged by the PIM application may be seamlessly integrated,synchronized and updated via the wireless carrier network with thedevice user's corresponding data items stored or associated with a hostcomputer system.

Communication functions, including data and voice communications, may beperformed through the communication subsystem 202 and through theshort-range communications subsystem 204.

The short-range communications subsystem 204 enables communicationbetween the mobile communication device 106 and other proximate systemsor devices, which need not necessarily be similar devices. For example,the short-range communications subsystem 204 may include a Bluetooth™communication module to provide for communication with the smart cardreader 104 in the case in which the smart card reader also implements aBluetooth™ communication module. As another example, the short-rangecommunications subsystem 204 may include an infrared device to providefor communication with similarly-enabled systems and devices.

With a view to allowing the mobile communication device 106 to employfunctionality built-in to the smart card 102, in the case in which thesmart card 102 has been provided by a particular vendor, it is knownthat the smart card framework module 230C of the mobile communicationdevice 106 may register a smart card driver supplied by the vendor.Employing functionality built-in to the smart card 102 may involve, forexample, providing input data to the smart card 102 and instructing thesmart card 102 to execute an application to process the input data to,in some cases, produce output data

As an early step in employing functionality built-in to the smart card102, the user establishes a communication coupling between the smartcard 102 and the smart card reader 104. In some embodiments, the smartcard 102 may be a so-called “contact” smart card, which is inserted intoa physical interface of the smart card reader 104 to establish acommunication coupling. In such a case, there is a physical coupling ofthe smart card 102 to the smart card reader 104. In other embodiments,the smart card 102 may be a so-called “contactiess” smart card, forwhich a communication coupling to the smart card reader 104 may beestablished over a wireless interface. The user then establishes acommunication coupling between the smart card reader 104 and the mobilecommunication device 106, if such a coupling has not already beenestablished.

Upon establishing a communication coupling between the smart card 102and the smart card reader 104, the smart card reader 104 may indicate,to the smart card framework module 230C of the mobile communicationdevice 106, that such a communication coupling has been recentlyestablished. Responsive to receiving the indication, the smart cardframework module 230C may arrange, through use of the short-rangecommunications subsystem 204, to transmit a RESET command to the smartcard 102.

Responsive to receiving the RESET command, the smart card 102 transmits,using the smart card reader 104, a response to the RESET command,Typically, smart cards are arranged to provide a response to a RESETcommand in a manner specific to the particular smart card 102.

It has been discussed above that the smart card framework module 230C ofthe mobile communication device 106 may register smart card driverssupplied by various vendors. Such registration may involve associatingvarious responses to a RESET command with specific smart cardapplications that have corresponding registered smart card drivers.

Responsive to receiving a response from the smart card 102, the smartcard framework module 230C may select a stored response from among aplurality of stored responses, each of the plurality of stored responsesbeing associated with a smart card application that is associated with aregistered smart card driver.

The smart card framework module 230C may then compare the receivedresponse to the selected stored response and determine whether theselected stored response matches the received response. Responsive todetermining that the selected stored response matches the receivedresponse, the smart card framework module 230C may then record anindication of the smart card driver associated with the selected storedresponse in association with an identity of the smart card 102 andconsider the task of selecting a smart card driver to be complete.

Responsive to determining that the selected stored response does notmatch the received response, the smart card framework module 230C maydetermine whether there are stored responses yet to be selected.Responsive to determining that there are stored responses yet to beselected, the smart card framework module 230C may then select a furtherstored response from among the stored responses yet to be selected andrepeat the comparing and determining until a match is found. Theselection may occur logically, progressing through a list of the storedresponses in a particular order.

Responsive to determining that there are no stored responses yet to beselected, the smart card framework module 230C may consider the task ofselecting a smart card driver to be complete.

It is typical that only one smart card driver is selected to facilitatecommunication with the smart card 102. The selection of a single smartcard driver is based on an assumption that only one application isavailable for execution on the smart card 102. However, that assumptionis becoming more frequently invalid as smart card vendors expand thecapabilities of their products. In an example case, a smart card vendormay include on a smart card two applications: one application specificto the vendor; and one application adhering to a particular standard.

For example, a given smart card from a given vendor may contain aPersonal Identity Verification (PIV) application. PIV applicationsgenerally adhere to a US Federal information Processing Standard (FIPS)number 201. The given smart card may also contain agiven-vendor-specific application.

Consider the smart card framework module 230C comparing a response,received from the given smart card, to each of a plurality of storedresponses. As discussed hereinbefore, the comparison may occurlogically, progressing through a list of stored responses in aparticular order, Accordingly, the smart card framework module 230C maylocate a match for the received response in a stored response that isassociated with the PIV application before locating a match for thereceived response in a stored response that is associated with thegiven-vendor-specific application. As a result, the smart card frameworkmodule 230C may select the smart card driver associated with the PIVapplication rather than the smart card driver associated with thegiven-vendor-specific application. Such a selection may be based onnothing more that the particular order in which the stored responses,associated with the various smart card drivers, are stored.

Upon selecting the smart card driver associated with the PIVapplication, the smart card framework module 230C may use the smart carddriver associated with the PIV application for communicating with thesmart card 102. While many similarities may exist between the PIVapplication and the given-vendor-specific application, it is unlikelythat the smart card framework module 230C using the PIV application willbe able to recognize objects in the given-vendor-specific application.Similarly, it is unlikely that the smart card framework module 230Cusing the given-vendor-specific application will be able to recognizeobjects in the PIV application,

The given vendor typically writes the smart card driver for thegiven-vendor-specific application, but another vendor may write a driverto talk to the standardized application. Due to the standardization, thedriver written to talk to the standardized application is expected tofunction properly with any smart card that implements the standardizedapplication; without regard for the identity of the smart card vendor.

One way to deal with dual-application smart cards involves the vendorsupplying a single driver, which is able to utilize both applications.However, such a solution involves significant work for the vendors,since each of the vendors adds standardized logic into the smart carddriver already configured for the given-vendor-specific application. Atthe same time, the manufacturer of the mobile communication device 106is generally unlikely to undertake to write code to talk to each ofpotentially many given-vendor-specific applications.

When there are two or more applications executable for a given smartcard, a user may only desire the use of one of the applications. Thismay be seen as problematic in that both drivers may be on the mobilecommunication device 106 at once; the standardized driver being includedin the code with which the mobile communication device 106 shipped andthe given-vendor-specific application being loaded onto the mobilecommunication device 106 in conjunction with the setup of use of thegiven-vendor-specific smart card.

In overview, a novel method for execution by the smart card frameworkmodule 230C does not stop considering stored responses upon locating amatch to a received response. Instead, according to the novel method,example steps of which are illustrated in FIG. 3, the consideration ofstored responses, and recording indications of those smart card driversassociated with stored responses that match the received response,continues until all stored responses have been compared.

Upon establishing a communication coupling between the smart card 102and the smart card reader 104, the smart card reader 104 may indicate,to the smart card framework module 230C of the mobile communicationdevice 106, that such a communication coupling has been recentlyestablished, In view of FIG. 3, responsive to receiving the indication(step 302), the smart card framework module 230C may arrange, throughuse of the short-range communications subsystem 204, to transmit (step304) a RESET command to the smart card 102. As discussed hereinbefore,responsive to receiving the RESET command, the smart card 102 transmits,using the smart card reader 104, a response to the RESET command.

Responsive to receiving (step 306) a response from the smart card 102,the smart card framework module 230C may select (step 308) a storedresponse from among a plurality of stored responses, each of theplurality of stored responses being associated with a smart cardapplication that associated with a registered smart card driver.

The smart card framework module 230C may then compare (step 310) thereceived response to the selected stored response and determine (step312) whether the selected stored response matches the received response.Responsive to determining (step 312) that the selected stored responsematches the received response, the smart card framework module 230C maythen record (step 314) an indication of the smart card driver associatedwith the selected stored response in association with an identity of thesmart card 102.

Upon recording (step 314) the indication of the smart card driverassociated with the selected stored response, the smart card frameworkmodule 230C may determine (step 316) whether there are stored responsesyet to be selected. Responsive to determining (step 316) that there arestored responses yet to be selected, the smart card framework module230C may then select (step 308) a further stored response from among thestored responses yet to be selected and repeat the comparing andconditional recording. The selection (step 308) may occur logically,progressing through a list of the stored responses in a particularorder.

Responsive to determining (step 312) that the selected stored responsedoes not match the received response, the smart card framework module230C may determine (step 316) whether there are stored responses yet tobe selected. Responsive to determining (step 316) that there are storedresponses yet to be selected, the smart card framework module 230C maythen select (step 308) a further stored response from among the storedresponses yet to be selected and repeat the comparing and conditionalrecording until all stored responses have been selected. The selection(step 308) may occur logically, progressing through a list of the storedresponses in a particular order.

Responsive to determining (step 314) that there are no stored responsesyet to be selected, the smart card framework module 230C may considerthe task of selecting a smart card driver to be complete.

According to the method of FIG. 3, the smart card framework module 230Cmay have previously recorded an indication of a first smart card driverassociated with a PIV application. The smart card framework module 230Cmay also have previously recorded an indication of a second smart carddriver associated with the given-vendor-specific application.

Occasionally, it will be desired that the smart card framework module230C import smart card certificates from the smart card 102. Similarly,it will be desired that the smart card framework module 230C importsmart card pointers from the smart card 102, in the case in which thepointers relate to the location of specific cryptographic keys stored onthe smart card 102. A smart card certificate often comprises a publiccryptographic key digitally signed with private cryptographic key, withthe private cryptographic key being associated with an issuer of thesmart card certificate. The issuer may be known as a CertificationAuthority or “CA”. The public cryptographic key may be associated withthe smart card 102.

Example steps carried out by the smart card framework module 230C in amethod of importing certificates from the smart card 102 are presentedin FIG. 4. The smart card framework module 230C first transmits a query(step 402) to each smart card driver of a plurality of registered smartcard drivers. The query identifies the particular smart card 102 to thesmart card driver and requests a response that indicates whether thesmart card driver supports the smart card 102. The smart card frameworkmodule 230C then receives responses (step 404) from the smart carddrivers.

The smart card framework module 230C then selects (step 406) one of thesmart card drivers that supports the smart card 102 and transmits acommand (step 408) to the selected smart card driver. In particular, thesmart card framework module 230C commands the selected smart card driverto import certificates from the smart card 102. As will be clear to aperson of ordinary skill in the art, the selected smart card driver mayimport only those certificates from the smart card 102 of which theselected smart card driver is aware.

The smart card framework module 230C then determines (step 410) whetherthere are smart card drivers that support the smart card 102 and towhich a certificate importing command has not yet been sent. Responsiveto determining (step 410) that there are smart card drivers that supportthe smart card 102 and to which a certificate importing command has notyet been sent, the smart card framework module 230C selects (step 406) afurther smart card driver and repeats the command transmission (step408).

Upon determining (step 410) that there are no more smart card driversthat support the smart card 102 and to which a certificate importingcommand has not yet been sent, the smart card framework module 230Cpresents (step 412) the user with a user interface, say, in the form ofa dialog, The dialog presents an identification of ail of thecertificates imported by the selected smart card drivers.

Advantageously, the user is generally unaware of any correlation betweena certificate identified in the dialog and the smart card driverresponsible for importing the identified certificate. An exception mayarise when the user is prompted to provide input to facilitate theimporting. For example, a password or a personal identification number(PIN) may be necessary to import certificates using a particular smartcard driver that corresponds to a particular application executed on thesmart card 102.

The applicants have recognized that, by recording indications of morethan one smart card driver compatible with a given smart card, someadditional complexity is added to routine smart card procedures.

In the course of importing certificates, as illustrated in FIG. 4, thesmart card framework module 230C may import at least one smart cardcertificate associated with a private key. As is known, a smart cardcertificate associated with a private key will contain a pointer to theprivate key on the smart card 102. Upon importing a smart cardcertificate associated with a private key, the smart card driverperforming the importing creates a private key object.

Example steps carried out by the smart card framework module 230C in amethod of signing a data object with a private key stored on the smartcard 102 are presented in FIG. 5. The data object may comprise, forexample, an e-mail message, an appointment request, a calendar entry oran address book entry. The smart card framework module 230C firstreceives (step 502) a request to use the private key, for example, foruse in signing a data object. Responsive to receiving such a request,the smart card framework module 230C selects (step 504), from among thecompatible smart card drivers, a candidate smart card driver, theselection being based on the candidate smart card driver being the smartcard driver that imported the pointer to the private key. The smart cardframework module 230C then calls (step 506) the candidate smart carddriver. As part of the call, the smart card framework module 230Cincludes a data object upon which the private key is to act.

Example steps in a method of reacting, at the candidate smart carddriver, to receiving a call (step 602) from the smart card frameworkmodule 230C are presented in FIG. 6. The candidate smart card driver mayarrange the presentation of a prompt (step 604) to prompt the user toprovide authentication data, such as a smart card PIN, to authenticateaccess to the private key. As there may be a distinct PIN associatedwith each application, the prompt may contain information about the PINto which the prompt relates. The candidate smart card driver receives(step 606) the authentication data from the user and transmits (step608) a signing command to the smart card 102. The signing command mayinclude such elements as a pointer to the private key, the data objectupon which the private key is to act and the authentication datareceived from the user.

Responsive to receiving the pointer, data object and authenticationdata, the application on the smart card 102 may execute. At thetermination of the execution of the application, the smart card 102 maytransmit a signature for the data object to the mobile communicationdevice 106.

At the mobile communication device 106, the candidate smart card driverreceives the signature (step 610) and passes (step 612) the receivedsignature to the smart card framework module 230C, The smart cardframework module 230C receives the signature (step 508, FIG. 5) from thecandidate smart card driver and makes use of the signature in theintended manner (step 510).

Notably, the selection of the smart card driver (step 504) among manycompatible smart card drivers would not typically be necessary in asmart card framework module that needs only to communicate with a singlesmart card driver, i.e., the smart card driver an indication of whichwas recorded.

As will be clear to a person of ordinary skill in the art, the methodfor which example steps are presented in FIG. 4 and the method for whichexample steps are presented in FIG. 5 may be applied to a wide varietyof situations beyond the examples. For instance, rather than importingcertificates in the method of FIG. 4, the smart card drivers may importfingerprint templates for use in biometric authentication. In the casein which the biometric authentication is handled by an application onthe smart card 102, the method of FIG. 5 may be appropriate with achange in the structure of the call to the smart card driver in step506.

The user of the mobile communication device 106 may enable multi-factorauthentication. In one example of multi-factor authentication, the useris prompted to supply a smart-card-specific PIN to unlock the mobilecommunication device 106.

Currently, to initialize the user authenticator, the user enters a PINwhile maintaining the smart card reader 104, which is coupled to thesmart card 102, in communication distance with the mobile communicationdevice 106. Responsive to receiving the PIN, the smart card frameworkmodule 230C queries the smart card drivers to select a smart card drivercompatible with the smart card 102. Upon selecting a smart card drivercompatible with the smart card 102, the smart card framework module 230Cissues a command to the selected smart card driver. According to thecommand, the selected smart card driver passes the PIN to the smart card102 to determine whether the supplied PIN is correct.

However, as discussed, there may be multiple smart card driversavailable to the smart card framework module 230C, in the case in whicheach smart card driver is for handling communications with a distinctapplication among multiple applications on the smart card 102.Furthermore, each of the multiple applications may have a different PIN.Accordingly, the PIN of the application associated with the selectedsmart card driver may not match the PIN supplied by the user.

According to aspects of the present application, as part of the firstauthentication subsequent to enabling mufti factor authentication, thesmart card framework module 230C prompts the user to choose a specificsmart card application to perform the authentication. Based on theuser's choice of application, to verify a subsequent supplied PIN, thesmart card framework module 230C calls the smart card drivercorresponding to the chosen application.

The user is only prompted to choose a smart card application during thefirst authentication subsequent to enabling multi factor authentication.During subsequent authentication session, the user simply enters the PINand the smart card framework module 230C calls the correct smart carddriver.

The above-described embodiments of the present application are intendedto be examples only. Alterations, modifications and variations may beeffected to the particular embodiments by those skilled in the artwithout departing from the scope of the application, which is defined bythe claims appended hereto.

1. A method of signing a data object with a private key stored on asmart card, said method comprising: selecting a driver corresponding tothe private key; calling the driver; receiving a signature from thedriver; signing the data object with the signature.
 2. The method ofclaim 1 wherein the data object comprises one of an e-mail message, anappointment request, a calendar entry or an address book entry.
 3. Amethod of providing a signature, said method comprising: in response toreceiving a call, prompting for authentication data; receivingauthentication data; transmitting a signing command to a smart card;receiving the signature from the smart card; providing the signature. 4.A short-range communications subsystem for providing a signature andsigning a data object with a private key stored on a smart card, thesubsystem operable to: receive a request to use the private key to signa data object; respond to the request by selecting a drivercorresponding to the private key; call the driver; at the driver,receive the call; authenticate access to the private key; transmit asigning command to the smart card; responsive to receiving the signingcommand, transmit a signature for the data object; and sign the dataobject with the signature.
 5. The subsystem of claim 4 where the call tothe driver includes a data object upon which the private key is to act.6. The subsystem of claim 4 where the signing command includes one of apointer to the private key, the data object upon which the private keyis to act and authentication data.